Test environment let anyone access live customer data

PWNED Welcome back to PWNED, the weekly column where we learn important life lessons about how we let cybercrims access our data through carelessness.

Hopefully, others’ mistakes provide an example of what not to do.

Today’s tales of woe comes courtesy of Richard Schut, Managing Director & AI Software Researcher at SmartRepl, a company that offers business AI services such as AI receptionists and sales automation.

In a past job, Schut was working for what he describes as a mid-size company during a security audit whose purpose was to identify any potential problems ahead of moving some local systems to the cloud.

Schut and his team discovered that there was a test environment that was accessible outside the network and connected to a database which had live customer information in it.

This was a gaping hole that a miscreant could have used to grab valuable information from the business.

“What made the situation particularly concerning was that the environment had originally been created for what the development team considered a short-term purpose,” he told The Register.

“They needed somewhere to demonstrate the application and test the migration, so a staging instance was spun up quickly.

It was never intended to become part of the company's permanent infrastructure.” Unfortunately, the test environment was still running months after it was initially set up.

And because those who created it did not expect unauthorized people to access it, they didn’t use the same authentication and access control methods that they would in production.

The SQL file containing the database was appropriately named master_test_final.sql, just in case there was any question about what it contained.

“It was a classic example of how security problems don't always come from sophisticated attacks or exotic vulnerabilities,” Schut said.

“Sometimes the biggest risk is simply something that was supposed to exist for a few hours, but was still sitting there six months later.” After Schut and his colleagues discovered the security vulnerability, he immediately restricted access to the staging environment.

Then he and his team started a review of other development and test environments in the company to make sure none of them was open to exploitation.