 |
| AppsGeyser main website |
AppsGeyseris a service that eases the creation of Android apps with just a few clicks. Literally, it allows users to create apps in three simple steps, so the web experience is translated to an app. This kind of applications introduce risks we have already talked about, since de programmer does not control the code and it may introduce unwanted security vulnerabilities.
In this case, AppsGeyser has deliberately introduced a function that disables the SSL certificate validation of HTTPS traffic in all apps developed from this platform. This vulnerability means that any navigation from an app created by AppsGeyser may be intercepted, forwarded, faked… No certificate from the remote server will be validated.
In order to be successful, the attacker has to be on the same local network as the victim. Then the attacker needs to access the victim’s traffic with any known technique (ARP spoofing, proxy control, gateway…) and analyze the traffic generated from any of the apps created with AppsGeyser. If an user of these apps visits an HTTPS website, the attacker would just have to introduce his own web signed with any certificate, and the victim would not notice anything. It would be like the perfect phishing. Or intercepting traffic between the victim and a secure website. Even if the victim does not explicitly visits an HTTPS webpage, the attacker could redirect him. For example, if an AppsGeyser apps visits some ads, the attacker could forward the user to a fake Facebook, Twitter, etc. webpage and ask for his password in any moment.
5.500 vulnerable apps
By using Path5, ElevenPaths’s app markets monitorization, correlation and research product, we have been able to detect 5.532 AppsGeyser apps created and still active on Google Play. During this year, more than 7.000 have been in this official platform, what confirms its popularity. There is even a browser developed with AppsGeyser that claims to be a tool to easily visit Twitter, Amazon, Facebook… in a totally insecure way. Some antivirus already detected AppsGeyser apps as badware, no matter the app’s features.. Now it is confirmed that they have good reasons to do it.
 |
| A browser with direct links to popular pages, created with AppsGeyser |
There are some serious institutions and companies that have used this method to create its app. Even very popular apps with hundreds of thousands of downloads. There are about 50 apps created with this platform that have been downloaded more than 100.000 times.
Maybe not every single one of them is vulnerable, but we have our doubts. In order to avoid being vulnerable, the original developer should have to add or remove the SSL explicit deactivation made by AppsGeyser. The vast majority of developers that have delegated the development of an app to a third party, it is not very likely they have the needed technical level for solving it. Moreover, AppsGeyser does not tell the developer that is invalidating the SSL check.
Why deactivating SSL? We think that is has been done to make everything easier for the creator using autosigned certificates for his web, or certificates that can not be validated by the system. AppsGeyser saves support incidents in its support system. Users will never see a “SSL validation error” with their apps. AppsGeyser disables SSL certificate validation and then they avoid problems to their support department, but jeopardizes any user of their apps.
Proof of concept
This proof of concept shows a MITM attack against an AppsGeyser app (https://play.google.com/store/apps/details?id=com.SantiniLabsWebBrowser) that allows to get encrypted traffic. The attacker has to enable IP forwarding and redirect HTTP AND HTTPS traffic to a webproxy in this machine.
Then he needs to launch an ARP spoofing attack (although any other technique would work).
The victim opens a Facebook session from the browser in the app.
The traffic is captured, although the user thinks is encrypted, since actually all is done with the non-trusted certificate in the webproxy:
The user would not be able to check the certificate from the browser, because the app does not allow this functionality.
Technical details
Technically, the failure is easy to spot. For example, we can have a look to the code from this browser created with AppsGeyser. It would be the same in any app created with this third party that have not explicitly fixed the vulnerability.
In the onCreate(…) method in the initial activity, we can find the following code snippet:
The first highlighted line, stores in the mStartupScreenViewContainer attribute the FrameLayout startupScreenContainer , that we will see when the app is launched. The second line, creates a controller from the FrameLayout with this code:
StartupScreenController class contains these attributes:
BrowserWebView will be the one in charge of showing web pages. To get it, it will need to use a WebViewClient object, established when building StartupScreenController:
You can see highlighted in this code, how BrowserWebView is recovered (in the initial activity layout) and how the WebViewClient is assigned as an instance of FullScreenBannerWebViewClient object.
As we can see, the class inherits from SimpleWebViewClient:
That in turn, inherits from WebViewClient, that, according to the Android API documentation, has the following method:
And this method is overwritten in SimpleWebViewClient with the following code, so, when an invalid SSL certificate is found, the page is still loaded with no warnings.
So, risky connections inside the apps, would be the ones from the objects that inherit from SimpleWebViewClient and BrowserWebViewClient. and provided that they do not overwrite onReceivedSslError behavior with paramSslErrorHandler.cancel().
