Mobile App Back-End Servers, Databases at Risk

Mobile application developers are putting enterprise data at risk by failing to secure the back-end servers and databases that feed their apps with data.

New research out today from Appthority shows a wide range of data exposures to and from back-end platforms based on both relational and non-relational database technology, including Elasticsearch, Redis, MongoDB, and MySQL, that are created due to developers' lack of implementation of authentication and blocking technology between the app and back-end servers.

Appthority calls the threat surface "Hospital Gown," but the risk to the enterprise is more serious than the cheeky name implies. As the report explains, the vulnerability is caused by app developers' failure to "properly secure the backend servers with firewalls and authentication" and exposes a huge volume of records that can easily be mined or ransomed by hackers with a trivial amount of reverse engineering and scanning.

Most disconcertingly, the exposure is difficult for enterprises to control or even detect because the breach occurs on the app vendors' back-end platforms.

"Only backend platform configuration improvements and possibly code changes within the affected app will eliminate the vulnerability. If the vulnerability is exclusively on the backend, even updating the app will not solve the problem," the report explains.

Because Appthority discovered dozens of terabytes of exposed data on a wide range of platforms, for this research it focused only on one platform for deeper technical analysis. The research team says it chose Elasticsearch due to enterprise preference for the non-relational database's flexible handling big data.

As the report explains, many developers use Elasticsearch and other programs like it to quickly mine and analyze persistently stored user data. The trouble is Elasticsearch, like many new non-relational databases, comes with a default configuration that's stripped down with few security assurances in place.

"Elasticsearch does not have built in security and access control and relies on external implementation of these security features with an authentication plugin or API for access, for example," the report explains. "If the Elasticsearch server is publicly accessible on the internet without these security features implemented, the data stored there will be available to anyone who knows where to look."

This is exactly what happened earlier this year when attackers hijacked hundreds of Elasticsearch servers in a crude ransom attack that was a copycat of a wave of attacks against similarly exposed MongoDB servers. According to security researchers with ERPScan who conducted custom scanning of exposed databases on the Internet when the attack hit, they founded over 43,000 instances of exposed Elasticsearch instances at that time.

"Those numbers can be considered a minimum," says Mathieu Geli of ERPScan. "The reason lies in the fact that administrators are testing and deploying in production new promising technologies to handle big data, but they usually forget about security aspects."

But as Appthority points out, it's not just administrators who are leaving Elasticsearch instances exposed. Non-relational databases like Elasticsearch, MongoDB, and Redis are designed with a minimalist bent to afford greater speed and flexibility in how applications can access and manipulate data.

The trade-off is that it falls on the developer who leans on Elasticsearch and similar back-end technologies to build in security hardening into their applications rather than relying on the platform itself to provide such hardening. This is the crux of the exposure described by Appthority.

In over 1,000 applications with the vulnerability, it is possible for a bad actor to reverse engineer the application to obtain an Elasticsearch server IP address and listen for traffic being sent in the clear with no authentication to that IP. Of those 1,000 applications, Appthority examined 39 in-depth and witnessed over 280 million records released by these few dozen applications. These were legitimate applications, "some developed by respected vendors with well vetted security practices," the report explains.

A few startling examples include Pulse Workspace - a VPN application widely used by organizations that includes pharmaceutical providers, a US federal court and a US missle company - as well as Jacto Apps, which connect IoT data from Jacto's commercial agricultural machinery to the company's centralized servers that store data on behalf of customers.

The vulnerability explained in the report offers a compelling case for organizations to get a better handle on how mobile data is stored once it leaves user's devices and enters the cloud.

"Every new mobile app that uses a back-end platform for data storage or analysis is a potential source of risk," the report's authors explain. "Enterprises relying on software developers to properly code and configure the backend connections are exposed."