Developers using the Twilio platform to build enterprise mobile communications apps have put call and text data at risk for exposure.

UPDATE Mobile app developers who code using the Twilio cloud-based platform and are forgetful about removing their hardcoded credentials have put businesses messaging data at risk for exposure.

The so-called Eavesdropper vulnerability, disclosed today by Appthority, has been around since 2011 and in apps downloaded likely more than 200 million times.

The researchers privately reported the bug in July; they found 685 enterprise apps (56 percent of them iOS apps) linked to 85 Twilio developer accounts. Many of the apps have been removed from the respective Apple and Google stores but as of August, 75 still remained on Google Play and 102 on the App Store.

“The affected Android apps had been downloaded up to 180 million times,” Appthority said. “Approximately 33 percent of the Eavesdropper apps found are business related. The exposure has been present since 2011. The scope of the exposure is massive including hundreds of millions of call records, minutes of calls and audio recordings, and text messages.”

Appthority said the hardcoded credentials afford an attacker “global access” to metadata in the developers’ Twilio accounts, including text messages, call metadata and recordings.

“Eavesdropper poses a serious enterprise data threat because a would-be attacker could access confidential knowledge about a company’s business dealings and make moves to capitalize on them for extorting actions or personal gain,” Appthority said, adding it did not listen to any of the exposed recordings, but based on the types of apps, it’s not far-fetched to assume sensitive business transactions were discussed and negotatied on these calls.

“A motivated attacker with automated tools to convert the audio to text and search for specific keywords will almost certainly be rewarded with valuable data,” Appthority said.

A request for comment to Twilio was not returned in time for publication. Twilio’s documentation provides guidance on securing credentials.

“Hard-coding API credentials isn’t a vulnerability as much as it is a poor coding practice, well-known to both the security and API industries. We’ve discouraged this practice for some time throughout our documentation and developer outreach,” Twilio said in a statement sent to Threatpost. “Appthority identified apps running in their customer environments where developers had done this, representing a very small fraction of the total accounts on Twilio.”

Appthority said an attacker would first need to find exposed enterprise apps built on Twilio; some market themselves as such. Using a YARA rule, for example, an attacker could then search for specific strings in order to identify Twilio IDs and either tokens or passwords authenticating the developer to the platform. Once having access to an account, Appthority said it would be trivial to exfiltrate call and messaging data.

“The attacker only needs to perform reconnaissance, exploitation, and exfiltration actions,” Appthority said. “There is no need to perform weaponization or the other steps as the files are undefended. Once the messaging and audio files have been exfiltrated, the attacker can run a simple script to convert audio files to text and search the text for keywords that would lead to proprietary or sensitive data.”

Twilio said it has notified each customer with an app identified by Appthority and has been working with them to rotate their API keys and implement secure solutions, Twilio said.

“We do not have any evidence that data shared through these apps was accessed by an unauthorized party,” Twilio said. “Many of those apps had long been decommissioned by their developers. Again, this is an example of poor coding practices, and in no way specific to Twilio.”

Earlier this year, Appthority disclosed the Hospital Gown vulnerability, which was linked to developers’ failure to secure backend servers communicating with mobile apps. Many of those servers are on platforms such as Elasticsearch, MongoDB and MySQL. Appthority said it found 21,000 exposed Elasticsearch servers and 43 terabytes of exposed data.