Analyzing an Android WebView exploit

#1

Post by nozepas » Tue, Dec 10, 2013, 8:08 AM UTC

Analyzing an Android WebView exploit
blogs.avg.com

Re: Analyzing an Android WebView exploit

#2

Post by girvo » Tue, Dec 10, 2013, 10:00 AM UTC

Damn I was hoping this bypassed permissions. It can still be dangerous; picture the Facebook app's permission structure, it uses a WebView (or used to anyway, I haven't used Android in a while now). An attacker could send a link that does something useful, or inject JavaScript into a legit page that when viewed in FB's app (coupled with an FB status worm, anyone?) sends messages to premium SMS numbers... the attacker could rack up quite a bit of money.

This is dangerous due to applications habit of requesting a lot of permissions, often for use cases that don't need that huge API in particular. The problem is, designing a more fine grained permissions structure that is tractable in terms of UI is a hard problem. This also points out one of the issues of androids lack of vendor supplied updates for anything less than a flagship phone :(

Does anyone know if WebView has been decoupled from the base OS in later versions? I know it has been hooked into Chrome now, right, so does that API get updated with Chrome itself?

Re: Analyzing an Android WebView exploit

#3

Post by dz0ny » Tue, Dec 10, 2013, 11:02 AM UTC

I think this is a bit misleading article. First in order to application to send SMS message or any other privileged action, it must declare that at install time (in manifest file). Second in order to send SMS and expose function to JS runtime, function must be of subclass of JavaScriptInterface class (pre JB), or you can use annotation if you are targeting JB+ devices.

This means function must be exposed and written before you can actuality use exploit. Bottom line you can't just send SMS from WebView just by "accident" :) And properly written applications should not expose that function in first place.

PhoneGap seem likely target for this exploit. Facebook, Instagram ... and many others not.

Re: Analyzing an Android WebView exploit

#4

Post by trurl42 » Tue, Dec 10, 2013, 12:46 PM UTC

dz0ny wrote: post #3

I think this is a bit misleading article. First in order to application to send SMS message or any other privileged action, it must declare that at install time (in manifest file). Second in order to send SMS and expose function to JS runtime, function must be of subclass of JavaScriptInterface class (pre JB), or you can use annotation if you are targeting JB+ devices. This means function must be exposed and written…

That is wrong.

Pre JB you can run any function by using reflection, as is demonstrated in the example.

anyjavaobject.getClass().forName("android.telephony.SmsManager").. etc.

Re: Analyzing an Android WebView exploit

#5

Post by keeperofdakeys » Tue, Dec 10, 2013, 1:13 PM UTC

girvo wrote: post #2

Damn I was hoping this bypassed permissions. It can still be dangerous; picture the Facebook app's permission structure, it uses a WebView (or used to anyway, I haven't used Android in a while now). An attacker could send a link that does something useful, or inject JavaScript into a legit page that when viewed in FB's app (coupled with an FB status worm, anyone?) sends messages to premium SMS numbers... the attacker…

The changes to the WebView are purely about the rendering engine (and possibly javascript engine). The API itself hasn't changed, as any old app will use the new WebView as well.

The actual rendering engine change is from a generic WebKit to that of Blink, used in Chromium. Chrome the application is then a rebranded Chromium, which compared to the WebView, has a lot of its own code separate from the WebView.