Another Day, Another Company Leaving Sensitive User Data Exposed Publicly On The Amazon Cloud
from the dysfunction-junction dept
What is it about companies leaving consumer data publicly exposed on an Amazon cloud server? Verizon made headlines after one of its customer service vendors left the personal data of around 6 million consumers just sitting on an Amazon server without adequate password protection. A GOP data analytics firm was also recently soundly ridiculed after it left the personal data of around 198 million citizens (read: most of you) similarly just sitting on an Amazon server without protection. Time Warner Cable also recently left 4 million user records sitting in an openly-accessible Amazon bucket.
You’d think that after all of this press attention fixated on a fairly basic (but massive) screw up, that companies would stop doing this. But you’d be wrong.
The latest company to fail at fundamental security practices is California’s Bank of Cardiff, which managed to leave millions of phone recordings made by employees — you guessed it — in an unsecured Amazon cloud bucket open wide to the general internet. Many of the phone recordings exposed include bank employees talking with customers about sensitive financial transactions:
“Many of the calls appear to be Bank of Cardiff employees phoning up individuals the bank has discussed loans with, or attempting to offer them one. One call includes a potential customer discussing their plans for obtaining financing either from Bank of Cardiff or a competitor. In another, an employee contacts a company focused on industrial equipment; Motherboard identified the company because of its hold music which includes the firm’s website. The company did not respond to a request for comment. In a third call, an employee contacted a company about a business loan.”
Yeah, whoops-a-daisy. The practice by lazy and/or incompetent companies has basically made a career for folks like UpGuard cyber risk analyst Chris Vickery, who has spent the better part of the last few years searching and exposing companies that can’t be bothered to secure their cloud accounts. But again, it’s absolutely incredible given the media exposure of this basic gaffe that every company on the planet hasn’t done an audit to make sure their brand isn’t the next one in lights for security incompetence.
Bank of Cardiff has yet to issue a public statement on the exposure, but it did finally lock down access to the data trove once journalists and security researchers (once again) did their jobs for them.
Filed Under: cloud, security
Companies: amazon, bank of cardiff
Comments on “Another Day, Another Company Leaving Sensitive User Data Exposed Publicly On The Amazon Cloud”
Like walking around wearing a neon target front and back
The practice by lazy and/or incompetent companies has basically made a career for folks like UpGuard cyber risk analyst Chris Vickery, who has spent the better part of the last few years searching and exposing companies that can’t be bothered to secure their cloud accounts.
Given how many companies seem to have a ‘shoot the messenger’ mindset I’m rather surprised someone who does that on a regular basis hasn’t been sued into the ground by companies looking to blame anyone but themselves for their lousy security practices.
Re: Like walking around wearing a neon target front and back
Something something Dentist guy??
There was another stupid company found to have their data accessible in the last day or so. Its only medical information so they ignored the researcher who tried to inform them ‘the right way’. Then he went public, they the claimed it was hacking, then claimed it was test info, then claimed ok it was only the info of some friends of ours…. The data was still online as they were making these statements.
The media jump on the evil superhacker narrative, because thats what they do. It is impossible to find any media willing to pillory a company for horrific practices.
If only we could get an executive order fixing actual problems instead of trying to fight the ‘zomg conservative bias’ delusion.
You can scan a Cloud for voice/address data
….but a Security team cannot whack all them moles.
I suspect the culprit is their funding or their AI deployment.
Victims could seek to sue, but would they win.
Re: You can scan a Cloud for voice/address data
Equifax was just successfully sued for a $0.10 win
There’s honestly no excuse for this any more. Amazon defaults everything to secure, you have to explicitly allow public access and any remotely competent team will have run an audit on existing buckets and scripts since these scandals started breaking. For this to happen on any kind of large scale, it’s either gross incompetence or deliberate sabotage.
Sadly, the most likely explanation is simply cost-cutting. A lot of companies making these kinds of mistakes are either too cheap to hire competent admins (usually leaving infrastructure decisions to developers, who will always favour ease of use over security) or otherwise leave too many security decisions in the hand of departments who don’t really have any right making them, often because they don’t want to pay for dedicated security staff until something bites them in the ass. That kind of cheap decision making is scarily common with banks, for some reason.
Re: Re:
Hey! Don’t go making sweeping statements like that. #notalldevelopers
Re: Re: Re:
Yeah, that was a little over generalised, but I was soured a little bit after working at a company with a contractor who refused to tell us accurate information about which ports some core software was running on because he hated working around firewalls. That was ridiculous, but it was clear that some minority of devs actually prefer to risk the entire company than make life a little more difficult for themselves.
I know that plenty of devs are conscious to some degree about security, and some extremely competent in that area, but my general experience is that at crunch time it gets left way in the background and not everybody is good at going back to tighten things down for production. My only experience with ransomware, for example, was when a dev decided to open elasticsearch ports to the public while I was on holiday to test a new reporting app release and forgot to remove the allow rule when he finished testing. Fortunately, my backup schedule was robust so we could laugh the demand off and only lost around 6 hours of overnight data in a company that’s focussed on retail business hours.
Bravo if you’re one of the good ones, but I fear you’re not in the majority, and I do find it’s slipping as less new devs have experience with setting up infrastructure and rely on cloud providers to do most of the heavy lifting.
Re: Re: Re:
It’s usually management that wants it bastardized.
Re: Re:
Financial institutions on the web astound me. I’ve run into several cases where my password was limited to less than 16 characters (I can’t have a long secure password, what?). I’ve also found many of them lack any kind of 2-factor authentication, and those that do seem to only allow SMS (a known broken attack vector) or email.
It’s just crazy that institutions that have large chunks of other people’s money are so bad at this.
pay us first
I’d rather be paid up front in cash (or in something that I can use whenever & wherever) for the use of my data, than to be paid in the form of a "free" application (e.g. Gmail) or "free" service (e.g. Experian credit monitoring).
There oughta be a law…
Big Guys
Again I’m a wonderin’. Was any of the executive’s personal information exposed? If not then why not? Do any journalists ask this at all when these break-ins occur? Just going out on a limb here and say their personal is kept safe and sound from such occurrences.
System default
Usually not hardening things and/or leaving system default ports, services and accounts running.
https://bit.ly/2SU5zn6
amazon cloud user
The Amazon Cloud is important for any business. I have one <a href="https://intorez.com/" target="_blank">It Company</a> . Amazon defaults everything to secure i’am appreciate with it. Your article is really informative. Waiting for your next article.