PWNED Welcome, once again, to PWNED, the weekly column where we recount the adventures of IT explorers who found their own pile of quicksand and then jumped right into it. This week's story involves keeping sensitive information in a very vulnerable place and then not protecting it adequately.
The tale comes to us courtesy of Stanislav Kazanov, head of strategic practices at Innowise, a software development firm. A few years ago Kazanov and his group were hired to perform compliance and data architecture audits on a fintech startup where execs had invested more than $1 million to develop a "military grade" security system complete with biometric MFA, endpoint detection, and a ton of physical security.
During the audit, Kazanov logged onto the company's SharePoint site and found a folder called "DevOps_Handoff" on the company-wide intranet that any employee could access. Within that folder was a spreadsheet with the very obscure and deceptive filename Prod_DB_Root_Creds_DO_NOT_SHARE.xlsx. Clearly, this naming convention would throw off any would-be hackers.
On the bright side, the Excel file was password-protected. So, at least there's that, but was there really that much protection?
When Kazanov asked the lead engineer for the password, he was so embarrassed that he looked at his feet and mumbled the answer: "It's the [company name] + [year]." We don't know the actual name of the company, but let's just say it was Contoso. The password would therefore be contoso2026. That's not exactly "admin123" but it's close enough to guess.
The lead engineer explained to Kazanov the reason for the file's existence. Apparently, the internal DevOps team and an external DBA team had a disagreement about which enterprise-grade password manager to use. To "temporarily" solve this disagreement, they dumped the root DB credentials and master AWS IAM keys into this spreadsheet, which had existed for a whopping eight months at the time our hero found it.
Our story ends here. We assume this problem was resolved after Kazanov's intervention and before tragedy struck. However, it shows that disagreements over how to secure resources can lead to dangerous compromises.
In this case, the internal DevOps team should have had the final say over what password manager the contractors and they would use. At no point should they have allowed this conflict to result in putting the secrets into a spreadsheet, even if the spreadsheet had strong password protection.
The most basic principle of cybersecurity is to give individual access and credentials to only those who really need it. But here the file was on an intranet that was accessible to all employees and even contractors like Kazanov. Since this was a fintech firm, the data involved could have related to millions or even billions of dollars of people's money. This is a serious situation and anyone who is this sloppy with security doesn't deserve to handle a dime in assets or transactions.
Have a story about someone leaving a gaping hole in their network? Share it with us at pwned@sitpub.com. Anonymity available upon request. ®
Source: The register