Remember last year there was this fuss about apps harvesting your location data and selling it?
Well, if you were doing that, the news today is Apple’s not going to put up with it, apparently:
So the question that’s no doubt on your mind today then, Dear Evil™ Readers, is: What ways are left to be Evil™ to my users?
I work on privacy research projects for the iOS platform in my free time. Those projects are in no way affiliated with my work or my employer…
Definitely not, we’d never suspect that! It’s not as if that employer has repeatedly needed to pay out tens of millions of dollars for privacy breaches…
… oh, wait.
All kidding aside, you probably want to read through the collection of articles on that page to be aware of things that could happen to you and how to protect against them, even if you’re not planning to Use Them For Evil™ —
— or, as may happen, inadvertently. No, seriously. In iOS Privacy: watch.user, that bit about
take pictures and videos without telling you
upload the pictures/videos it takes immediately
Yeah, that was one of the more memorable bug reports we’ve had, back in this kinda-Vine kinda-Instagram thing we worked on back in the day:
QA: Troll, why is your code uploading pictures of my girlfriend?
TROLL: Dude, my code is not uploading pictures of your girlfriend.
QA: *holds up device*
TROLL: Huh. OK … how is my code uploading pictures of your girlfriend?
(Lesson Learned there: even if you use timers only for photo countdowns, your app should listen for applicationSignificantTimeChange, or strange things may happen.)
But the one that we actually want to draw your attention today that you definitely need to read is how to protect your app from other people using it for Evil™:
Third-party SDKs can often easily be modified while you download them! Using a simple person-in-the-middle attack, anyone in the same network can insert malicious code into the library, and with that into your application, as a result running in your user’s pockets.
31% of the most popular closed-source iOS SDKs are vulnerable to this attack, as well as a total of 623 libraries on CocoaPods…
… What’s the worst that a malicious SDK could do?
- Steal sensitive user data, basically add a keylogger for your app, and record every tap
- Steal keys and user’s credentials
- Access the user’s historic location data and sell it to third parties
- Show phishing pop-ups for iCloud, or other login credentials
- Take pictures in the background without telling the user
The attack described here shows how an attacker can use your mobile app to steal sensitive user data…
And as an aid to that, there’s a repo set up now:
A crowd-sourced list of SDKs and how they protect their downloads with HTTPs.
Since you are responsible for your app’s behaviour whether the source of Evil™ is your code or your SDKs’ code, it behooves you considerably to acquaint yourself with the risks here — so read up thoroughly, and good luck with not being the next privacy-violating headline!