Android Tutorial [B4X] Tip - Modified server response

While analyzing a Crashlytics crash report of a small app of mine I was surprised to see the following error:

Fatal Exception: java.lang.NumberFormatException
For input string: "<html><head></head><body><script type="text/javascript">try{if(parent.document.location==document.location) window.location="xxxxx"referer=&startm=201203";}catch(e){}</script></body></html>

The app sends a request to a server implemented with B4J. The server responds with a number. The code looks like this:

Wait For (CreateJob(...)) JobDone(j As HttpJob)
       If j.Success Then
           SavedGroupInfo.GroupId = j.GetString '<--- crash here

The user internet provider modified the server response and returned a JavaScript that does something (it is related to "safe internet" feature).

Bottom line is that even if you are calling your own web service you cannot assume that the server response will not be modified...

BTW, I recommend adding Crashlytics to your apps. It provides more information than Google Play and the data is sent automatically.

 

[Harris]

Geezzzz...
Was the response number wrapped up in the return somewhere?

I use the same method all the time to update the record (with return ID) to SENT. If it doesn't get updated, it will continue to be sent - forever.

 

[OliverA]

returned a JavaScript that does something (it is related to "safe internet" feature).

Wow. How does this even make sense? So let's add some JavaScript to a return that had no JavaScript, since JavaScript is just so ridiculously safe (yes, that was sarcasm). BTW, I tried to search for this (wrapping HTTP returns in JavaScript), but could not find anything. Pointers would be welcome.

 

[Erel]

Was the response number wrapped up in the return somewhere?

No. The original link was included. My guess is that the JavaScript sends the URL to the "safe internet" server and then redirects to that page. I might be wrong here.
This of course doesn't work when the request is made outside of a browser.

I tried to search for this (wrapping HTTP returns in JavaScript), but could not find anything. Pointers would be welcome.

Search for JavaScript injection.
Example: https://stackoverflow.com/questions/4113268/stop-mobile-network-proxy-from-injecting-javascript
https://security.stackexchange.com/...ecting-strange-codes-to-every-website-i-visit

SSL doesn't help as they install their own certificate.

 

[OliverA]

Search for JavaScript injection.

For some reason I was looking for additional JavaScript that helped with security and found no hits. The two samples listed show 1) ISP's injecting ads and 2) ISP's automatic bandwidth reduction scheme. The security aspect would be interesting to see, but I smell ... .

Bottom line is that even if you are calling your own web service you cannot assume that the server response will not be modified...

SSL doesn't help as they install their own certificate.

I guess this incident really shows that one really needs to host their site (via VPS or otherwise), use their own certificate and process EVERYTHING over HTTPS. If anything happens with this configuration, then your dealing with an actual MITM attack.

 

[Erel]

I guess this incident really shows that one really needs to host their site (via VPS or otherwise), use their own certificate and process EVERYTHING over HTTPS. If anything happens with this configuration, then your dealing with an actual MITM attack.

In this case SSL doesn't help. I've checked the ISP instructions (in Hebrew). They include installing a custom certificate authority. This is indeed a MITM "attack".

 

[OliverA]

They include installing a custom certificate authority.

In this case, I think they are injecting the JavaScript before the encryption. I could see that happening if it is a shared hosting system instead of a VPS. Of course, if they are doing that, they are totally cancelling out the benefits of a custom certificate authority. Now, if this is a VPS and this is still happening, then somehow the ISP has access to the VPS or they are really doing something clever here (not in a good sense though, since this would break the trust in HTTPS).

 

[Erel]

It is not related to the VPS. Once the user installs your own root certificate, https can be decrypted and modified. Example: https://mitmproxy.org/

The explanation is here: https://docs.mitmproxy.org/stable/concepts-howmitmproxyworks/

 

[OliverA]

Once the user installs your own root certificate

That's the key though! Did the device that runs your "small app" do that? If it did not, the MITM should fail. Or is your app accepting all certificates? If so, that's defeating the purpose of HTTPS too. So if they inject JavaScript with a Proxy, it would break most accesses to the site, since I just can't see that everyone that visits that site just goes ahead and installs the Proxy's root CA. Now, I'm not contesting that deep pockets (state actor's) can't get around this by forging CA's, but in this case I'm pretty sure that 1) this is a shared web host, not a VPS and 2) that they are injecting the JavaScript before the encryption happens. BTW, I'm not picking a fight here, I'm just hoping to clarify some points, since if this were a true MITM (without having to install a root cert per device accessing the site) that is not discoverable when accessing the site via HTTPS and is capable of altering in-flight HTTPS content, we are having some huge issues here on the order of breaking the internet (the HTTPS portion).

 

[Erel]

Did the device that runs your "small app" do that?

Yes. The customer is using an internet provider that provides a safe internet service. As part of this service they install a root certificate on the device. They install it once and this allows the internet provider to act as a man in the middle. The root certificate allows it to forge certificates of all sites.

Or is your app accepting all certificates?

No.

this is a shared web host, not a VPS

The app interacts with this server. It is a VPS with a valid certificate.

BTW, I'm not picking a fight here

Of course not. Don't worry