Another huge database exposed millions of call logs and SMS text messages
January 15, 2019 at 13:27 PM EST
An unprotected server storing millions of call logs and text messages was left open for months before they were found by a security researcher. If you thought you’d heard this story before, you’re not wrong. Back in November, another massive exposed database was leaking text messages — including password resets and two-factor codes — on […]
An unprotected server storing millions of call logs and text messages was left open for months before they were found by a security researcher.
If you thought you’d heard this story before, you’re not wrong. Back in November, another massive exposed database was leaking text messages — including password resets and two-factor codes — on millions of users.
This time around, it’s a different company: Voipo, a Lake Forest, California communications provider, exposed tens of gigabytes worth of customer data.
Security researcher Justin Paine found the exposed ElasticSearch 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 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 though we didn’t validate the credentials (as doing so would be unlawful), web addresses in the logs pointed directly to customer login pages.
Paine said, and noted in his write-up, that the database was exposed since June 2018, and 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. Other files contained streams of text messages, including the sender and the recipient, and their content.
A log showing an incoming call. (Screenshot: TechCrunch. Data: Justin Paine)
Some of the numbers in the call logs were scrubbed, Paine said, but text message logs contained full numbers.
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 opportunity to upgrade to app-based protections.)
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.
It’s clear based on a cursory review 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 scale of the data exposed.
TechCrunch also has no reason to believe that the data is not real customer data.
Dick told 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.