14 DAY TRIAL // It appears that Verizon had problems securing MongoDB databases months before the most recent data breach that allowed hackers to steal at least 1.5 million customer records and then put them up for sale on the Dark Web.
MacKeeper Security Researcher Chris Vickery is now saying that almost three months before this incident, he also discovered one of Verizon's MongoDB servers exposed online without any form of authentication.
According to Mr. Vickery, he says he found the server on December 22, 2015. After sending an email to Verizon on the same day, he says he received a reply almost after a month, on January 19, 2016.
Verizon fumbled the initial fix
Ironically, Verizon answered that they've secured the server, even if the researcher hadn't provided its IP address. Of course, after checking for himself, Mr. Vickery discovered that Verizon didn't actually secure the server at all, and then moved on to provide its IP address to the Verizon staff.
The server was taken offline in the end, Verizon claiming that it was only a test server with dummy data. Once again, Mr. Vickery proved Verizon's staff wrong, providing the company with a backup of the data found on the server.
The company reviewed its initial assessment saying that it was a test server, which was populated with real data to debug an incident affecting the company's network.
According to Jim Matteo, director of Verizon Corporate Security, the server was put online around November 6, 2015, after a network disruption.
Server exposed internal Verizon data, no customer information
This test environment eventually ended up storing information such as secret Verizon encryption and authentication keys (PSKs), access tokens and password hashes for various services and accounts, and metadata for DVR, VOD, and Fios Hydra Verizon services.
The researcher's only regret is for not publishing a public disclosure about the incident, which would have caused enough agitation in the public media and at Verizon to trigger a security audit for other MongoDB databases which would have probably prevented the most recent breach.
