

Paypal Android App Remote Code Execution - ge0rg
https://labs.mwrinfosecurity.com/advisories/2014/03/10/paypal-remote-code-execution/

======
stusmall
>It was recently discovered that applications do not even need to have a
Javascript Interface in their code to be vulnerable to this attack. This is
because a Javascript Interface is implemented core webview code in Android
versions before 4.2. Meaning that every single application that loads a
webview over cleartext is vulnerable to this attack.

Maybe its because I haven't properly had coffee yet or because I've never used
WebView in android but I'm having trouble parsing this. From the small code
snippet they provided it shows them enabling javascript and adding an
interface. Is this just a general comment for other apps that are working on
HTTP or broken HTTPS or does it relate to this exploit?

~~~
dmayer
There is a CVE (CVE-2012-6636) [1,2] related to the general issue they are
mentioning. Basically one could use reflection to call any public function on
any class in the app. Since Android 4.2 one now needs to add the
@JavascriptInterface decorator to explicitly expose methods. At least this is
my current understanding of this.

If the app then uses HTTP or HTTPS without certificate validation, it is
easily possible to inject JavaScrpipt code even when no Cross-Site Scripting
vulnerability exists in the app.

[1]
[https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-66...](https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-6636)

[2]
[https://labs.mwrinfosecurity.com/advisories/2013/09/24/webvi...](https://labs.mwrinfosecurity.com/advisories/2013/09/24/webview-
addjavascriptinterface-remote-code-execution/)

~~~
stusmall
Thank you very much for the details and CVE link.

------
whitehat2k9
public void onReceivedSslError(WebView paramWebView, SslErrorHandler
paramSslErrorHandler, SslError paramSslError) {
paramSslErrorHandler.proceed(); } }

Wow, good job PayPal.

------
double051
Ignoring invalid certificates is a never a good thing to do.

------
chippy
> 25/02/2014 Paypal claim no risk to Paypal brand

That does not sound good.

~~~
tkorri
This also caught my eye... But then again there are many examples where Paypal
has handled issues badly, so I'd guess this just the way they want their brand
to be perceived.

------
zaidf
Someone unknown added a phone number and a new mobile pin to my paypal account
recently. I called paypal support and they walked me through changing the pin.
Few minutes later, the pin was changed once again by the unknown person. I
call paypal again and they walk me through a similar process again. Finally it
stopped but it left me feeling very vulnerable especially because I'd enabled
two factory auth and it did little to prevent it.

Weird enough no funds from my account disappeared. Not sure if me acting so
far(within minutes of compromise) had to do with it.

------
jonny_eh
I'm guessing an engineer added the 'proceed' call during development because
the dev servers had invalid certs, and they forgot to change it back before
committing.

------
yuhong
I wonder what happened inside PayPal that cause the Android app to be treated
differently or whatever it is?

------
tokenizerrr
What kind of code can be executed through the Javascript interface? They seem
to claim it's not specific to Paypal's implementation and these seem fairly
common. I was under the impression they only expose various methods and
variables. How can they be exploited?

~~~
gberger
An attacker can show the user a page identical to PayPal's and convincingly
ask them for their credentials. The submission would send the credentials to
the attacker.

~~~
tokenizerrr
Yeah, but that seems to be different from code execution.
[https://news.ycombinator.com/item?id=7493849](https://news.ycombinator.com/item?id=7493849)
seems to be closer to the truth.

