5.500 apps potentially vulnerable to Man in the Middle attacks in Google Play

Monday, December 22, 2014

It has been discovered than AppsGeyser, an app creator "with just a few clicks", deactivates the SSL certificate validation in its apps. An attacker on the same network as the user running these apps, will be able to inject any page when browsing from the affected apps, or view and modify webs that should be protected. This app generator is very popular and (as they show in their own web, there have been installed almost a thousand million apps). There are 5500 AppsGeyser apps in this moment in Google Play. Let's analyze the problem, and its details.

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().


Miguel Ángel García
miguelangel.garcia@11paths.com

Sergio de los Santos
ssantos@11paths.com

Latch USB Monitor: New tool to monitor PNP devices with Latch

Thursday, December 11, 2014

Latch USB Monitor is a tool that monitors Plug 'n Play device (PNP) changes in Windows and gives the user the possibility of tracking incoming devices, and react accordingly to a preconfigured Latch response. For instance, it would allow to block USB ports so it will not recognize a new inserted memory USB stick until it is authorized with the movile device.

This means that Latch USB Monitor will ask Latch servers what to do when a certain PNP device is detected in a Windows machine. So the administrator has a tool to potentially react to plugged devices, and modify the behavior and scripts launched in any way, at any moment, just sliding a bar from his mobile device.

How it works

Latch USB Monitor works as a service and has a GUI to configure it. That means it still works and monitors incoming devices even when no user is logged in. The service is constantly monitoring any device with the characteristics given by the user. When it occurs, it asks Latch servers and reacts in the way that the user has configured it.

It may as well be used as an alerting system, with no action associated to an event. So if a device is plugged to the machine, a blocking message is sent by Latch to the mobile device, but no action is taken.


Latch USB Monitor with some configured rules

 How to install it

No special instructions. Just accept the license and choose the path. If, for the sake of security, you do not want the service to run as SYSTEM, you may change it to whatever account you wish, as long as it has privileges to run as a service, and network access.

A config file is created in XML format. This file contains sensitive information. Take care with the permissions specially in shared computers.

Pairing with Latch

First of all, a Latch account has to be set with a pairing token. Go to Latch management and add the App ID and secret. A timeout is specified here. This means that if the computer is not connected to a network or, for any other reason it cannot get a response from Latch in the specified time limit (0 milliseconds by default which corresponds to no timeout) the "no response" action is applied.

How to add and configure a device

Each monitored device, may have these fields:
  • Device (optional): If your device is currently plugged in, you can choose it from this dropdown menu where all attached devices are listed.
  • Description (optional): Giving a meaningful description of the device helps you better identify it in the main list.
  • Device Instance ID: The ID that uniquely identifies a device in a Windows machine. When an arriving Device Instance ID is detected it goes through a matching system that can be used to discard or allow the rule. If the string set matches, the Latch query will be launched. This is treated as a string, so "Starts with", "Contains"... may be used to match.
  • Operation ID: The operation ID used in Latch.
  • Actions.Open (optional): If the Latch query responds with an "on", the process specified here will be launched, with the specified argument set (optional).
  • Actions.Closed (optional): If the Latch query responds with an "off", the process specified here will be launched, with the specified argument set (optional).
  • Actions.No response (optional): If the Latch query doesn't respond (because there's no connectivity, for instance, after the timeout declared in "Latch settings"), the process specified here will be launched, with the specified argument set (optional).

    Device details with pendrive example

    The tool is written in C# and may be freely downloaded from: https://elevenpaths.com/downloads/LatchUSBMonitor.zip. You may want to check out Latch Event Monitor, too.

    We encourage you to use it.

    PhpMyAdmin fixes a XSS detected by ElevenPaths (CVE-2014-9219)

    Thursday, December 4, 2014

    On November 28th, while our Faast team was developing an intrusion module for PhpMyAdmin MySQL manager, we detected a new cross site scripting vulnerability not known so far in this popular program. It has been privately reported to the team responsible for PhpMyAdmin security and the CVE-2014-9219 has been assigned. It affected all known versions.

    Vulnerability and fix announce

    PhpMyAdmin security team has reacted promptly and in just three days they have fixed the problem and released a new version. The vulnerability (currently exploitable in any version previous to 4.2.13.1) relies in a bad filtering in the "url.php" file. The function htmlspecialchars was being incorrectly used.

    The figure below shows the applied patch where htmlspecialchars function is replaced by PMA_escapeJsString.


    Commit 9b2479b7216dd91a6cc2f231c0fd6b85d457f6e2 with the fixing line


    Just filtering HTML special characters, its exploitation was trivial. Besides, it was possible to bypass anti-XSS protections in browsers, because the injected code was reflexed into a "script" tag. This kind of vulnerabilities are very common in web applications, and allow different attacks, as obtaining session cookies, as shown in the figure below.

    Exploiting the vulnerability

    If you are using PhpMyAdmin, it is recommended to update as soon as possible to latest version (4.2.13.1) or applying the patch available here. Besides, we recommend using Faast that, of course, already detects this vulnerability.

    Finally, remember we have a Latch plugin for PhpMyAdmin. All the information about how to install it, is here.

    Manuel Fernández
    manuel.fernandez@11paths.com