Welcome to your new telco job – here's sudo access to a database with full customer info stored in the clear

PWNED Welcome back to PWNED, the weekly column where we register some of the worst tech security mistakes our readers have ever seen. Our goal: to help you not do the same.

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.

This week's tale of code carelessness comes courtesy of a database administrator we'll Regomize as Joker. Back in the first decade of the 21st century, she went for a job interview at one of the USA's leading national cellular carriers.

What she saw would make you want to swap your SIM.

After a successful meeting with a hiring manager, Joker was hired on the spot.

Within hours the company sudo-level access to a database server, then instructed her to "take a look" at some of the databases.

Joker soon realized the carrier's security was no laughing matter as she found herself accessing the main production server for the company's data services division, overseeing all services for the mobile web. This story took place in a time before the iPhone, so she was looking at nasty little versions of websites comressed for viewing on their BlackBerries or flip phones.

After peeking around some more, Joker discovered that she had access to the master customer table. It contained nightmarish quantities of personally identifiable information: names, addresses, Social Security numbers, billing info, and even full 16-digit credit card numbers. All of this info was stored in the clear, with no encryption or obfuscation. The CVVs were missing from some credit card info, but many were present.

"There was a central billing system upstream on Amdocs servers, but this database also had billing details so they didn't have to reach back upstream to Amdocs if users asked to provision new services," Joker said.

After Joker informed management about the mess, they deleted the offending info and forced the developers to go upstream again for billing information, just like they should have been doing in the first place.

Joker, like any reasonable DBA, assumed access to this information would be tightly controlled - not made available to new staff with full access rights on their first day.  

She also assumed her new employer would tokenize key pieces of data because that technique means certain info – say credit card and Social Security numbers – would not be visible in the same table as a customer's name and address. Instead, there would be tokens linking back to the actual numbers stored in a secure token vault. This is common in payment systems.

If Joker were less ethical or someone else had gained admin access, they could have exfiltrated large amounts of sensitive data. Permissions should start from a zero-trust assumption and provide only what someone needs to do their job.

Joker said that when she later moved on to work for a major online retailer, security was front and center, proving that some people did get it, even back in the George W. Bush era. ®