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.

REG AD

“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.”

REG AD

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. 

Tell us your story

Have a story about someone leaving a gaping hole in their network? Share it with us at 
pwned@sitpub.com. Anonymity is available upon request.

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.

The takeaway here is as accessible as that SQL file: Don't get lax with security simply because an environment is made for testing. Even if the test server was live for only a day, that’s a day where it could be exploited.

“The incident completely changed how I look at staging environments. If an environment has access to real data, it needs to be treated as a real security asset — regardless of whether the developers expect it to exist for a day, a week, or six months,” Schut said.®