[zhongjiewu]

Sounds like very dangerous attack and not very difficult to implement.

DNS hijacking:

1. Quicker DNS response than router to pollute the Android's DNS

2. Rouge AP that pretend to be common free public wifi like "att", "starbucks", "cablewifi" or "Free Public WiFi"

3. De-authenticate valid AP connections and force user to try rouge WIFI

MITM attack: 1. ARP spoofing

[trustlook]

Correct ;-)

[vezzy-fnord]

That's a universal network attack though, how is it an exclusive vulnerability to this app?

[zhongjiewu]

You would never be able to install an app without user click "install" etc.

This one uses Javascript Bridge vulnerability to execute high privilege code in your Android. The attack code is javascript to be interpreted to Java calls in Android.

You wouldn't be able to do that in iPhone though.

[lstamour]

Bit confused as to how this can't happen on iOS "just because," as iOS apps could be targeted in a similar way. Really the message here should be that SSL with certificate-pinning is a must for apps that inherently run in untrusted environments with an inability to easily inspect the security of the network traffic without MITMing it yourself. Wish this was a security feature on the app store -- if, in automated testing or in device logs, an app was entirely secure or insecure with its communication, just as we've padlock icons in browsers today.

[gress]

iOS apps cannot be targeted in this way because they don't have the JavaScript bridge.

[void-star]

Not exactly. iOS 7+ introduced Cocoa<->Javascript bridging capabilities in the public APIs. Before that, similar iOS APIs had existed as "private" ones (so, very uncommonly used outside of apple's own apps).

iOS doesn't bridge Javascript to _Java_ which is why this particular attack wouldn't work. But the JS<->Cocoa stuff is still pretty young, so wait and see ;)

[trustlook]

Thx Zhongjie ;)