Another huge database exposed millions of call logs and SMS text messages

An unprotected and exposed server storing millions of call logs and text messages has been found by a security researcher.

If you thought you’d heard this story before, you’re not wrong. Back in November, another telecoms company, Voxox,  href="https://techcrunch.com/2018/11/15/millions-sms-text-messages-leaked-two-factor-codes/">exposed a database containing millions of text messages — including password resets and two-factor codes.

This time around, it’s a different company: Voipo, a Lake Forest, Calif. communications provider, exposed tens of gigabytes worth of customer data.

Security researcher Justin Paine found the exposed database last week, and reached out to the company’s chief technology officer. Yet, the database was pulled offline before Paine even told him where to look.

Voipo is a voice-over-internet provider, providing residential and business phone line services that they can control themselves in the cloud. The company’s backend routes calls and processes text messages for its users. But because one of the backend ElasticSearch databases wasn’t protected with a password, anyone could look in and see streams of real-time call logs and text messages sent back and forth.

It’s one of the largest data breaches of the year — so far — totaling close to seven million call logs, six million text messages and other internal documents containing unencrypted passwords that if used could have allowed an attacker to gain deep access to the company’s systems.

TechCrunch reviewed some of the data, and found web addresses in the logs pointed directly to customer login pages. (We didn’t use the credentials, as doing so would be unlawful.)

Paine said, and noted in his write-up, that the database contains call and message logs dating back to May 2015. He told TechCrunch that the logs were updated daily and went up to January 8 — the day the database was pulled offline. Many of the files contained highly detailed call records of who called whom, the time and date and more.

A log showing an incoming call. (Screenshot: TechCrunch. Data: Justin Paine)

Some of the numbers in the call logs were scrubbed, Paine said, but the text message logs contained the numbers of both the sender and the recipient, and the contents of the message itself.

An SMS text message sent just after New Year’s. (Screenshot: TechCrunch. Data: Justin Paine)

Similar to the Voxox breach last year, Paine said that any intercepted text messages containing two-factor codes or password reset links could have then “allowed the attacker to bypass two-factor on the user’s account,” he said in his write-up. (Another good reason why you should to upgrade to app-based authentication.)

But Paine didn’t extensively search the records, mindful of customers’ privacy.

The logs also contained credentials that permitted access to Voipo’s provider of E911 services, which allows emergency services to know a person’s pre-registered location based on their phone number. Worse, he said, E911 services could have been disabled, rendering those customers unable to use the service in an emergency.

Another file contained a list of network appliance devices with usernames and passwords in plaintext. A cursory review showed that the files and logs contained a meticulously detailed and invasive insight into a person or company’s business, who they’re talking to and often for what reason.

Yet, none of the data was encrypted.

In an email, Voipo chief executive Timothy Dick confirmed the data exposure, adding that this was “a development server and not part of our production network.” Paine disputes this, given the specifics and amount of the data exposed in the database. TechCrunch also has no reason to believe that the data is not real customer data.

Dick said in an email to TechCrunch: “Almost immediately after he reached out to let us know the dev server was exposed, we took it offline and investigated and corrected the issue.” He added: “At this time though, we have not found any evidence in logs or on our network to indicate that a data breach occurred.”

Despite asking several times, Dick did not say how the company concluded that nobody else accessed the data.

Dick also said: “All of our systems are behind firewalls and similar and don’t even allow external connections except from internal servers so even if hostnames were listed, it would not be possible to connect and our logs do not show any connections.” (When we checked, many of the internal systems with IP or web addresses we checked loaded — even though we were outside of the alleged firewall.)

However, in an email to Paine, Dick conceded that some of the data on the server “does appear to be valid.”

Dick didn’t commit to notify the authorities of the exposure under state data breach notification laws.

“We will continue to investigate and if we do find any evidence of a breach or anything in our logs that indicate one, we will of course take appropriate actions to address it [and] make notifications,” he said.

Correction: an earlier version of this story incorrectly said the database was exposed for six months. Some of the exposed data, such as passwords and API keys, dated back six months. We regret the error.


Got a tip? You can send tips securely over Signal and WhatsApp to +1 646-755–8849. You can also send PGP email with the fingerprint: 4D0E 92F2 E36A EC51 DAAE 5D97 CB8C 15FA EB6C EEA5.