iBackDoor: High-Risk Code Hits iOS Apps | Hacker News Reader

iBackDoor: High-Risk Code Hits iOS Apps

fireeye.com

44 pointsOatseller7 comments

I'm sorry, but as an advertisement for their network protection services, they're going to have to prove maliciousness beyond what is currently possible by downloading any app from the App Store.

What they describe is a JavaScript to objc bridge in this library - would would be completely containerized by the embedding application. No, this bridge cannot be used to write outside of the apps container, nor steal keychain credentials outside of the ACLs provided by this application.

If you're embedding a third party library, any of the above could be true. But your user will still be protected to the extent provided by the app security model.

So this is just annoying FUD.

I still maintain the FUD factor, but a more careful reading shows that they are aware that this third party library is restricted to the apps container.

But I don't see how this could be considered a back door since the app developer specifically embedded the library for the functionality it provides. It's more like inviting a vampire to dinner. It can't enter your house if not invited. (And vampires are too "proud" for the servents enter for.). Ok, as a metaphor, this needs work...

> As of November 4, we have identified 2,846 iOS apps containing the potentially backdoored versions of mobiSage SDK. Among these, we observed more than 900 attempts to contact an ad adSage server capable of delivering JavaScript code to control the backdoors. We notified Apple of the complete list of affected apps and technical details on October 21, 2015

When will the list of apps be public?

Why do they say 'potential' backdoor when it is so clearly a backdoor? I know it's good to hedge your bets but is there some kind of legal reason they say it like this? I'm curious because it is so common.

Because you never really know until you _really know_. I know there have been times in my life that I was 100% sure of something and never thought there was a way I could be wrong, but somehow new info came to my attention and turned everything upside down. What if there's some kinda stuff in a chinese document that FireEye hasn't read yet, stating that this is normal functionality of the SDK and the developer, who read the docs thoroughly, knows that it does this. Better to just present the facts and stick with "suspect" or "alleged" type verbage and only drop the bet-hedging when it is known without a shadow of a doubt. The fact Apple removed the apps does strongly indicate FireEye at least found something suspicious and the readers of this article are probably mostly convinced at that point anyway without FireEye having to risk officially throwing around accusations.

Also, nowadays it's getting a bit too easy to blame hacking/spying on the Chinese & Russians so you don't want to accuse them until you're absolutely sure. If you're wrong, it's going to look extra bad.

Thank you for your wisdom. I think I vaguely grasped that but I let bias prevent me from fully thinking through the other possibilities.

That API looks a lot like Cordova.

Reply on news.ycombinator.com